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LESSONS  LEARNED 
FROM  DEVELOPING  THE 
ABCS  6.4  SOLUTION 

COL  HAROLD  GREENE,  USA,  AND  ROBERT  MENDOZA 


In  response  to  Army  decisions  during  the  1  980s  to  develop  increasingly 
lethal  platforms  aided  by  automation,  several  automated  command  and 
control  (C2)  systems  were  developed  to  support  various  battlefield 
functional  areas.  These  C2  systems  were  successful  during  Operations 
Enduring  Freedom  and  Iraqi  Freedom;  however,  each  system  was  evolving 
independently  of  the  others.  In  2003,  after  the  Good  Enough  Army  Battle 
Command  Systems  (ABCS)  decision  by  Army  leaders,  Program  Executive 
Office  Command,  Control,  and  Communications  Tactical  initiated  a 
concerted  battle  command  integration  effort.  The  Army  designated  ABCS 
version  6.4  software  as  the  standard  version  to  field.  This  article  reviews 
lessons  learned  from  the  systems  engineering  and  integration  of  ABCS 
6.4,  moving  from  stovepipe  development  and  testing  to  an  integrated 
and  interoperable  System-of-Systems,  leading  to  operational  evaluation 
preparation  and  fielding. 


In  order  to  fight  and  win  wars,  the  Army  must  be  organized,  directed,  controlled 
supported,  and  sustained  in  a  manner  that  guarantees  mission  accomplishment. 
The  Army  of  the  21st  century  combines  flexible  organizational  elements,  battle- 
proven  techniques  of  leadership,  and  a  basic  concept  of  command  and  control  (C2) 
that  combines  historical  experience  and  modem  information  technology.  The  Army 
Battle  Command  System  (ABCS)  provides  commanders  the  battle  command  archi¬ 
tecture  necessary  to  gain  and  maintain  the  initiative  and  successfully  execute  mis¬ 
sions  assigned  by  the  National  Command  Authority  (NCA).  The  ABCS  version  6.4 
is  the  single  System-of-Systems  (SOS)  by  which  Army  forces  pass  critical  opera¬ 
tional  information  to  perform  missions  in  support  of  national  objectives.  The  ABCS 
6.4  provides  improvements  in  both  flexibility  and  interoperability  over  previous 
C2  systems. 
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BATTLE  COMMAND  TOP-DOWN  FOCUS 


In  2003,  the  Chief  of  Staff  of  the  Army  (CSA)  directed  that  the  Army  shift  its 
funding  efforts  from  developing  the  Battle  Command  architecture  from  the  bottom- 
up  to  one  that  is  focused  on  developing  the  architecture  from  the  top-down. 
Additionally,  he  directed  the  fielding  capability  to  the  entire  Army.  Prior  to  this 
decision,  the  entire  Army  Battle  Command  suite  was  only  programmed  for  a  fraction 
of  the  Army  force.  This  decision  redirected  resources,  stopped  development  of  the 
ABCS  software  suite  at  the  current  Block  IV,  and  redirected  all  available  funding  to 
fielding  a  C2  system  to  the  entire  force  structure. 

Development  of  ABCS  is  now  driven  by  a  top-down  approach  that  will  have  to 
take  into  account  joint  requirements  and  communications  architecture.  The  SOS  will 
be  designed  to  allow  C2  with  data  feeds  between  various  command  levels,  up  to  and 
including  a  Theater-wide  Combined  Forces  Command  Center.  It  will  provide  a  com¬ 
mander  enhanced  C2  through  more  automation  of  staff  functions  and  by  moving  to¬ 
ward  meeting  the  commander’s  needs  of  operating  in  a  joint  environment.  Not  only 
must  it  provide  C2  capabilities  across  the  Army  and  facilitate  joint  interoperability 
for  Army  units,  it  must  be  affordable  for  fielding  across  the  entire  force. 


A  Family  of  Systems  that  Comprises  1 1  Battle  Command  Systems 


GCCS-A 

Global  Command  and 
Control  System— Army 


DTSS 

Digital  Topographic 
Support  System 


IMETS 
Integrated 
Meteorological 
System 

BCS3 

Battle  Command 
Sustainment 
System 

AMDWS 
Air  and  Missile 
Defense  Workstation 


ASAS 
All-Source 
Analysis  System 


MCS 

Maneuver  Control  System 


FBCB2 

Force  XXI  Battle 
Command— Brigade 
and  Below 


TAIS 

Tactical  Airspace 
Integration  System 


AFATDS 
Advanced  Field 
Artillery  Tactical 
Data  System 


FIGURE  1.  ABCS  6.4  GOOD  ENOUGH  SYSTEMS 
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WHAT  IS  ABCS  6.4? 


The  ABCS  consists  of  1 1  battlefield  automated  systems,  which  comprises  the  core 
for  ABCS  and  provides  the  capabilities  that  support  the  warfighter’s  mission  needs 
(Figure  1).  Each  Battlefield  Automated  System  (BAS)  aids  in  planning,  coordinating, 
and  executing  operations  by  providing  access  to  and  the  passing  of  information  from 
a  horizontally  integrated  command  and  control  network.  Systems  within  ABCS  support 
soldiers  specializing  in  a  battlefield  functional  area;  for  example,  maneuver,  intelli¬ 
gence,  fire  support,  and  logistics.  The  BAS  is  grouped  into  five  Battlefield  Functional 
Areas  (BFAs) — Maneuver,  Fire  Support,  Air  Defense,  Intelligence/Electronic  Warfare 
and  Battle  Command  Sustainment  Support. 

The  ABCS  6.4  differs  from  earlier  versions  due  to  the  incorporation  of  the 
centralized  information  server.  The  addition  of  the  ABCS  Information  Server  (AIS) 
into  the  Tactical  Operations  Center  (TOC)  structure,  with  its  Publish  and  Subscribe 
Server  (PASS)  methodology,  enables  the  horizontal  information  exchange.  The  AIS 
assists  the  1 1  BAS  systems  to  interoperate  as  one;  thus,  ABCS  is  called  a  system- 
of-systems. 

The  ABCS  6.4  is  an  improvement  of  the  previous  command  and  control  system, 
ABCS  6.3  Delta,  but  with  the  additional  enhancements  necessary  to  maintain 
interoperability  with  the  other  ABCS,  Software  Block  1  and  Joint  C2  systems.  It 


Within  a  Joint  Context 


Current  Force 


Top  Down 


Future  Force 


1  Enhanced  Capabilities 

Accelerated  Development  1 

▼ 

^  and  Fielding  ^ 

Battle  Command 

Implement  Good  Enough 
solution  &  Command  Post 
Standardization 
Providing  Green/Red 
Requirements 

Focus  on  Commander’s  Needs 


capabilities  bridge 
current  to  future 
force  and  enable 
interdependent 
network-centric 
warfare 


Obtain  Redundant,  Secure,  Mobile 
Universal  Connectivity 
Implement  Improved  BC  Capabilities 
Within  Joint  GIG  Architecture 
Maintain  Focus  on  HUMINT  and  Cl 
Resource/Evolve  Knowledge  Centers 
Balance  Manned,  Unmanned,  Air  and 
Ground  Sensors 

Emphasize  Presentation/Visualization 


•  Implement  one  BC  System  with  Emphasis  on  Joint  Interoperability 

•  Accomplish  Multi-level  Security 

•  Minimize  Tactical  Footprint 

•  Provide  Ubiquitous  Access  to  C2  Info  via  Web  Technology 

•  Support  Ultra-Light  Information  Appliances 

•  Provide  Enhanced  Mobility  &  Improved  Bandwidth  for  Global  Access 


FIGURE  2.  EMERGING  VISION  NET-CENTRIC  BATTLE  COMMAND 


197 


meets  the  Army’s  good  enough  prioritized  requirements  and  provides  a  net-centric 
data  management  capability  on  a  dedicated  server.  Its  program  schedule  aligns  with 
previous  ABCS  7.0  plans,  which  stopped  development  at  the  current  ABCS  6.4  version. 
However,  ABCS  6.4  will  need  further  coordination  with  the  joint  community  to  ensure 
interoperability  with  joint  and  coalition  forces. 

BACKGROUND  ON  ABCS  6.4 

Prior  to  1995,  several  independent  projects  were  underway  to  leverage  the  rapid 
growth  in  Internet-related  technologies  and  develop  systems  that  improve  command 
and  control  capabilities  in  several  battlefield  functional  areas.  In  1995,  Program 
Executive  Officer  Command,  Control,  and  Communications  Tactical  (PEO  C3T), 
headquartered  at  Fort  Monmouth,  NJ,  began  working  with  the  Training  and  Doctrine 
Command  (  TRADOC),  along  with  elements  of  the  4th  Infantry  Division  at  Fort  Hood, 
TX,  to  develop  the  ABCS.  The  PEO’s  goal  was  to  join  those  evolving  and  developing 
systems  into  an  SOS  concept,  to  enable  horizontal  networked  integration  and 
interoperability  amongst  the  systems  in  a  common  operating  environment. 


BATTLE  COMMAND  SYSTEM  LESSONS 

Initial  assessments  from  units  in  theater  indicated  that  Force  XXI  Battle  Command 
Brigade-and-Below  (FBCB2)  and  Blue  Force  Tracker  (BFT)  were  winners  and  that 
e-mail,  chat  rooms  (Instant  Messaging),  and  Web  pages  were  critical  for  collabora¬ 
tion  and  information  dissemination.  Additionally,  mobile  command  posts  enabled  by 
satellite  communications  were  critical,  given  the  operational  tempo  and  extended 
distances.  However,  development  of  the  correlated  red  picture  did  not  satisfy  tactical 
requirements.  In  addition,  databases  and  data  exchange  mechanisms  did  not  support 
the  frequent  task  reorganizations — incremental  and  dynamic  naming  conventions  were 
required.  Also,  with  the  conclusion  of  initial  ground  operations,  it  was  evident  that 
Security  and  Stability  Operations  (SASO)  applications,  which  enabled  full  spectrum 
operations,  were  a  necessity. 


CHIEF  OF  STAFF  OF  THE  ARMY  GUIDANCE  (AUGUST  2003) 

During  the  summer  of  2003,  with  our  Army  at  war,  the  PEO  C3T’s  top  priority  was 
to  expedite  the  delivery  of  innovative,  integrated,  and  operationally  suitable  warfighter 
capability  to  the  field.  The  CSA  wanted  to  focus  on  the  commander’s  operational 
needs,  plus  Joint  and  Coalition  Interoperability,  which  are  designated  as  the  Top  7 
plus  1.  They  are: 

1.  Friendly  Locations. 

2.  Current  Enemy  Situation. 
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3.  Running  Estimate  (Current  Combat  Power/Future  Combat  Power/Staff  Estimates). 

4.  Graphic  Control  Measures. 

5.  Fragmentary  Orders  (FRAGOs). 

6.  Commander’s  Situation  Report  (SITREP). 

7.  Fire  Support  Coordination  Measures/Capabilities  Overlay. 

8.  Joint  and  Coalition  Interoperability. 


ESTABLISHMENT  OF  AN  OVERARCHING 
INTEGRATED  PRODUCT  TEAM 

The  PEO  C3T,  Major  General  Michael  R.  Mazzucchi,  designated  the  Project 
Manager  for  Ground  Combat  and  Control,  Colonel  Greene,  as  the  trail  boss  to  lead 
the  effort  in  rapidly  developing  an  SOS  and  getting  it  to  the  PEO  C3T’s  Central 
Technical  Support  Facility  (CTSF)  at  Fort  Hood,  Texas  by  April  30,  2004.  To  jump 
start  the  process,  Colonel  Greene  established  an  ABCS  6.4  good  enough  Execution 


FIGURE  3.  PROGRAM  EXECUTION 
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Integrated  Product  Team  (EIPT)  for  ABCSs  that  included  all  Army  stakeholders  (Figure 
3).  One  of  the  mandates  of  the  Integrated  Product  Team  (IPT)  was  to  proceed  in 
accordance  with  the  CSA  directive  to  stop  development  of  the  ABCS  at  version  6.4 
and  refocus  efforts  and  funding  toward  a  top-down  architecture  that  met  the 
Commander’s  top  seven  needs  plus  Joint  interoperability. 

The  ABCS  6.4  good  enough  EIPT  was  chartered  to: 

■  Coordinate  the  execution  of  the  good  enough  program,  now  commonly  called  ABCS 
6.4,  at  all  Army  levels. 

■  Serve  as  the  focal  point  to  ensure  interoperability  and  programmatic  synchroniza¬ 
tion  among  ABCS. 

■  Coordinate  and  interface  with  Army,  Joint,  and  combined  forums. 

■  Provide  the  SOS  oversight  on: 

-  Integrated  requirements; 

-  Integrated  architecture; 

-  Integrated  and  synchronized  program  and  execution  schedule; 

-  Project  funding  status; 

-  Identification  of  issues  and  risk  areas; 

-  Risk  mitigation  plans  and  tracking; 

-  Certification  and  evaluation  status;  and 

-  Development  of  an  Acquisition  Program  Baseline. 


The  biggest  differeiue  between  previous  ABCS 
versions  and  ABCS  6.4  is  that  it  improves  and 
automates  data  sharing  and  horizontal 
interoperability  among  the  systems. 


The  EIPT  quickly  determined  a  high-risk  area — the  ABCS  6.4  schedule  was  very 
aggressive  and  success-oriented.  A  risk  analysis  showed  that  the  software  had  to  be 
very  mature  on  entry  to  the  Central  Technical  Support  Facility  (CTSF)  in  April  2004; 
however,  there  was  no  slack  in  the  ABCS  6.4  good  enough  development,  testing, 
training,  and  fielding  schedule,  and  there  was  no  time  for  materiel  release  approval 
prior  to  the  first  unit  rotating  into  theater.  A  mitigation  strategy  was  developed  to 
separate  the  fielding  and  development  process,  and  to  field  a  previous  version  of 
ABCS  to  units  deploying  for  Operation  Iraqi  Freedom  (OIF). 
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Warfighter  Perspective  & 
User  Feedback 


69  “Good  Enough” 
Operational  Requirements 


\ 


TSM  &  PM  tech 
feasibility  revie 


866  Technical  Supporting 
Reqs  derived  &  prioritized 


ABCS  6.4  software  delivi 
to  system  test  in  April  ‘( 


Field  ABCS  6.4 


across  force  within  48  months... 


FIGURE  4.  DEVELOPING  THE  ABCS  6.4  SOLUTION 


DEVELOPING  THE  ABCS  6.4  SOLUTION 


The  ABCS  6.4  was  designed  to  rapidly  provide  a  good  enough  standard  battle 
command  capability  across  the  Army  based  on  the  OIF  lessons  learned.  The  ABCS 
6.4  brings  together  the  BASs,  integrating  them  as  components  in  an  interoperable 
SOS  environment  to  enhance  the  commander’s  ability  to  command  and  control  forces. 
Development  of  ABCS  6.4  is  proceeding  from  the  warfighter’s  perspective  and 
incorporates  user  feedback  that  defines  69  operational  good  enough  requirements. 
(See  Figure  4.) 

The  biggest  difference  between  previous  ABCS  versions  and  ABCS  6.4  is  that  it 
improves  and  automates  data  sharing  and  horizontal  interoperability  among  the  systems. 
To  achieve  a  higher  level  of  integration  and  interoperability,  ABCS  6.4  will  have  an 
important  feature  that  is  new  to  ABCS  called  the  Publish  and  Subscribe  Server  (PASS). 
The  ABCS  6.4  core  systems  collectively  operate  in  an  SOS  environment  designed  to 
provide  the  battle  commander  and  staff  with  timely,  accurate,  and  integrated  mission- 
critical  information  to  support  effective  command  and  control  functions.  This  sharing 
of  information  across  the  network  assists  in  providing  the  common  operational  pic¬ 
ture — an  important  facet  of  digital  battle  command. 


ABCS  6.4  DEVELOPMENT  AND  PROCESSES 


The  ABCS  is  being  developed  under  the  sponsorship  of  PEO  C3T  for  the  U.S. 
Army.  Each  component  has  its  own  program  manager  and  developer,  and  they  are 
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responsible  for  developing  and  testing  all  component  functionality.  The  ABCS  6.4 
EIPT  immediately  identified  numerous  issues  and  challenges  in  design,  horizontal 
integration,  scheduling,  and  time  constraints.  Some  of  the  initial  issues  captured  from 
the  IPT  kickoff  meeting  held  in  the  fall  of  2003  include: 

■  A  needed  mindset  change  from  stovepipe  development  to  an  SOS. 

■  A  need  for  a  technical  design  review  and  the  development  of  processes. 

■  The  development  of  an  SOS  architecture. 

■  Schedule  constraints  with  respect  to  system  delivery,  testing,  and  certification. 

■  A  need  for  highly  aggressive  scheduling  in  fielding  to  the  next  OIF  rotational  unit. 

■  Identification  of  which  OIF  rotation,  and  what  units,  is  ABCS  6.4  likely  to  be 
fielded  to. 

■  Identification  of  a  test  unit  and  approval  for  coordination  with  the  unit. 

■  A  need  for  a  coordinated  schedule  and  plan  for  the  engineering  releases  of  C2 
software  that  would  lead  to  the  final  software  submission  by  the  target  date  of 
April  30,  2004. 

■  A  need  for  strong  coordination  of  the  PASS  Schema  Library  with  all  stakeholders. 

■  A  need  for  feasibility  proof  of  technical  approach — use  of  PASS. 

■  Identification  and  resolution  of  bandwidth  requirements  and  capabilities. 

■  Development  of  a  critical  path  to  the  ABCS  6.4  Initial  Operational  Test  (IOT)  that 
includes: 

-  Timing  of  software  development  and  delivery  to  the  CTSF; 

-  Plan  for  interim  software  drops  and  testing; 

-  Testing  and  certification  timelines; 

-  Plan  and  schedule  for  meeting  documentation  requirements; 

-  Plan  for  unit  new  equipment  training  programs; 

-  Plan  for  unit  training,  fielding,  testing,  and  operational  evaluation  assess¬ 
ment,  and; 

-  Fielding  Army-wide. 

From  this  first  meeting,  the  EIPT  quickly  identified  issues  and  risk  areas,  started 
an  effective  tracking  of  program  risks,  and  developed  mitigation  plans  to  reduce  areas 
of  significant  risk.  An  integrated  program  schedule  was  developed,  and  a  systems 
engineering  design  review  was  held — which  would  have  been  more  effective  if  it  had 
been  conducted  much  earlier.  However,  immediate  solutions  to  the  integration  problem 
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led  to  standardizing  ABCS  on  Extensible  Markup  Language  (XML),  defining  ABCS 
in  commercial  off-the-shelf  compatible  information  architecture,  and  providing  Web 
services  through  a  publish  and  subscribe  interface  as  the  integration  engine.  With 
delivery  of  an  AIS  within  a  couple  of  months  and  coordination  of  the  PASS  Schema 
Library  with  all  stakeholders,  the  EIPT  worked  toward  finalizing  the  software  deliv¬ 
ery,  testing,  and  certification  schedule.  The  initial  and  primary  focus  of  the  EIPT  was 
the  development  of  the  PASS  XML  data  schemas  and  to  formalize  the  emerging  good 
enough  architecture. 

Several  technical  working  groups  were  established  to  conduct  the  design  review 
and  resolve  any  discrepancies  in  understanding  among  the  various  stakeholders.  The 
working  groups  were  instrumental  in  finalizing  a  matrix  showing  which  systems  are 
publishing  and/or  subscribing,  tied  to  specific  schemas,  and  which  are  relying  on 
messaging.  All  issues  with  the  architecture  and  the  data  management  schemas  were 
fair  game,  and  these  working  groups  were  critical  in  resolving  issues  on  the  spot. 
Participation  of  various  stakeholders  and  agencies  was  highly  encouraged,  and  working 
groups  operated  in  open  channels  with  no  exclusions. 


Signifi<ant  issues  arose  in  the  SOS  engineering 
as  ea<h  program  postured  for  optimum 
solutions  for  its  program . 


Other  subordinate  IPTs  were  formed  to  aggressively  work  the  good  enough  issues 
in  testing,  training,  programmatics,  and  logistics.  Due  to  decentralization  from  work¬ 
ing  with  1 1  separate  contracts,  one  important  lesson  learned  was  the  need  for  a  common 
set  of  reporting  metrics  to  measure  progress,  and  the  need  for  it  to  be  set  up  fairly 
early  in  an  SOS  environment.  Through  frequent  and  extensive  high-level  meetings, 
the  EIPT  received  commitment  from  project  and  product  managers  for  interim  drops 
to  the  CTSF  to  alleviate  schedule  and  integration  risk.  To  lessen  user  concerns  and 
earn  their  support,  numerous  briefings  and  presentations  were  given  throughout  the 
Army  and  to  the  DoD.  The  EIPT  worked  with  Software  Blocking  initiatives,  the  Army 
Test  and  Evaluation  Command  (ATEC),  and  Department  of  the  Army  (DA)  level 
agencies  to  coordinate  activities.  These  meetings  synchronized  Army-wide  efforts, 
resolved  issues,  and  gained  DA  level  guidance  and  support  in  working  through  the 
numerous  documentation  requirements. 

Another  significant  lesson  learned  was  the  need  for  senior  management’s  focus  in 
the  early  phases  of  the  project  on  the  systems  engineering.  Significant  issues  arose 
in  the  SOS  engineering  as  each  program  postured  for  optimum  solutions  for  its  pro¬ 
gram.  The  EIPT  leader  hosted  weekly  technical  IPTs  to  mediate  disputes  and  to  keep 
the  overall  program  moving  forward  until  the  software  was  delivered. 
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TESTING 


Before  certification  and  Intra-Army  Integration  Certification  (IAIC)  testing,  the 
software  is  developed  and  tested  under  the  sponsorship  of  its  program  or  project 
manager.  Each  BAS  is  responsible  for  testing  its  own  functionality;  therefore,  each 
has  its  own  test  plan.  The  BAS  software  is  then  released  to  all  other  BASs  for 
development  and  incorporation  in  their  respective  software  to  ensure  horizontal 
integration.  Once  this  is  complete,  pairwise  testing  is  performed  with  each  BAS  and 
the  Foundation  Software  will  occur.  Upon  completion  of  pairwise  testing,  the  BAS 
software  is  delivered  to  the  CTSF  for  integration  as  an  SOS.  One  key  and  immediate 
task  for  the  Technical  IPT,  in  close  coordination  with  the  Test  IPT  (both  supporting 
the  EIPT),  was  the  development  of  an  integrated  and  synchronized  schedule  leading 
to  the  April  30,  2004,  software  drops  to  the  CTSF.  This  was  a  significant  lesson 
learned.  The  Test  IPT  was  delegated  to  the  CTSF  and  the  EIPT  initially  did  not  give 
it  enough  attention.  Also,  the  EIPT  did  not  have  buy  in  from  the  programs,  nor  detailed 
testing  schedules.  We  never  did  get  to  pairwise  testing. 


Soldiers,  the  requirements  < ommunity ,  material 
developers,  produtt  managers,  industry,  software 
programmers,  engineers,  tethnidans,  the  test 
(ommunity,  trainers  and  (ombat  systems  all 
partidpated  in  the  ABCS  6.4  testing. 


After  the  software  drop  was  made  in  April  2004,  the  battle  command  systems  went 
though  a  test-fix-test  cycle.  The  Development  Test  and  Integration  (DT&I),  or  test- 
fix-test  phase  of  ABCS  6.4  software,  was  conducted  at  the  CTSF  in  Fort  Hood,  Texas. 
This  was  intended  as  a  unique  testing  window  to  afford  the  individual  BASs  the 
opportunity  to  come  together  as  an  SOS,  and  to  test  new  interfaces,  features,  and 
functions  prior  to  entry  into  certification  testing.  Operational  threads  form  the  basis 
of  testing;  however,  these  threads  arrived  after  DT&I  began  and  required  numerous 
changes.  When  anomalies  were  found,  the  product  managers,  in  close  coordination 
with  CTSF  personnel,  developed  solutions  on  the  spot.  Following  this  test- fix-test,  an 
IAIC  test  started  in  the  fall  of  2004.  To  conduct  the  IAIC  test,  a  realistic  model  of 
the  ABCS  network  was  set  up  at  the  CTSF,  and  simulations  of  actual  operations  were 
run  through  the  various  systems.  Soldiers,  the  requirements  community,  material 
developers,  product  managers,  industry,  software  programmers,  engineers,  technicians, 
the  test  community,  trainers,  and  combat  systems  all  participated  in  the  ABCS  6.4 
testing. 
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The  ABCS  6.4  SOS  has  completed  the  DT&I  or  test-fix-test  phase  successfully  in 
terms  of  its  ability  to  enter  into  certification.  However,  it  entered  into  certification 
late  and  with  several  known  issues.  The  most  significant  issues  relate  to  thread  de¬ 
velopment,  test  planning,  collaboration,  and  data  reporting  and  metrics. 

After  the  formal  integration  testing  at  the  CTSF,  an  ABCS  6.4  Test  Event/Software 
Block  One  Operation  Evaluation  (SWB1  OPEVAL)  will  be  conducted  during  a  division 
training  exercise  under  multiple  Test  and  Evaluation  Master  Plans  (TEMPs).  All  1 1 
ABCS  core  systems  will  be  tested  under  realistic  operational  conditions  with  trained 
operators  using  the  unit’s  standing  operating  procedures  (SOPs)  and  tactics,  tech¬ 
niques,  and  procedures  (TTP).  The  purpose  of  this  OPEVAL  is  to  provide  data  for 
evaluating/measuring  system  effectiveness,  suitability,  and  interoperability  of  the  ABCS 
6.4  core  systems  and  available  SWB1  equipment  in  a  realistic  operational  setting. 
The  ABCS  6.4  Test  Event/SWBl  OPEVAL  will  focus  on  situational  awareness,  C2 
messaging  capabilities,  message  exchange,  and  critical  mission  threads  of  those  BAS 
systems  requiring  a  milestone  decision.  During  the  Test  Event/SWBl  OPEVAL,  soldiers 
will  deploy  and  employ  the  ABCS  6.4/SWB1  systems  predominately  at  division-, 
brigade-,  and  battalion-level  command  posts  in  accordance  with  the  Army’s  new  Heavy 
Division  Modular  Design/Architecture. 


LESSONS  LEARNED 

Systems  engineering  was  a  big  challenge,  due  to  uncertainties  in  both  technical 
and  operational  architectures,  a  highly  compressed  schedule,  evolving  technical  de¬ 
sign,  and  the  need  for  synchronization  across  commands.  Some  initial  issues  were: 
SOS  integration  after  the  fact;  undefined  communications  and  network  architectures; 
ABCS  good  enough  not  being  in  current  Army  documentation;  operational  require¬ 
ments  documents  (ORDs)  in  various  stages  of  approval  (all  had  to  be  reworked); 
executing  program  development  against  ORDs  in  staffing;  undeveloped  Basis  of  Issue 
Plans  (BOIPs);  the  need  for  operational  architecture  development  for  different  levels 
of  command  (light  and  heavy  brigades  and  divisions,  Stryker  Brigade  Combat  Teams 
[SBCTs],  Corps,  and  units  under  the  modularity  concept);  operational  threads  under 
development  (and  a  need  for  global  data  formats),  the  need  for  a  publish-and-sub- 
scribe  matrix;  and  the  mapping  of  publish-and-subscribe  XML  and  threads  to  ORDs. 
Another  major  concern  was  executing  programs  against  ORDs  with  potential  modi¬ 
fications.  Major  changes  to  ORDs  in  the  approval  process  would  have  broken  good 
enough  programs;  however,  this  was  mitigated  through  close  coordination  with  Train¬ 
ing  and  Doctrine  Command  (TRADOC);  Headquarters,  Department  of  the  Army 
(HQDA)  G3  Operations;  and  the  Assistant  Secretary  of  the  Army  (Acquisition, 
Logistics,  and  Technology)  (ASA[ALT]). 

The  accelerated  success-oriented  schedule  and  diverse  organizations  made  risk  an 
inherent  component  of  both  ABCS  as  an  SOS  and  on  the  ABCS  6.4  test  program. 
This  was  further  compounded  by  a  lack  of  normal  systems  engineering  process  and 
documentation  upfront.  Having  a  well-defined  and  -documented  testing  policy  is  critical 
for  the  test,  integration,  and  qualification  activities.  For  a  program  with  the  scope  and 
complexity  of  ABCS  6.4,  it  is  imperative  to  develop  a  coordinated  organizational 
plan  from  the  beginning  that  addresses: 
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■  Risk  Identification. 

■  Risk  Analysis. 

■  Risk  Mitigation  Planning. 

■  Risk  Monitoring  and  Control. 

Schedule  and  technical  contingencies  need  to  be  aggressively  monitored  and 
managed.  The  ABCS  6.4  IPT  found  that  the  community  was  behind  on  test  planning 
and  had  a  test  strategy  in  need  of  development.  With  less  than  a  year  until  formal  test 
certification,  a  test  unit  had  not  yet  been  identified,  and  the  Army  did  not  have  a 
practical  test  plan.  Additionally,  the  EIPT  was  working  with  a  test  timeline  that  was 
out  of  sync  with  Software  Blocking,  and  a  source  of  funds  for  FY04  test  activities 
had  not  been  identified. 

LESSONS  FOR  THE  COMMUNITY 

BAS  Centric  versus  SOS  Focus.  ABCS  6.4  good  enough  was  moving  from  a 
loosely  coupled  architecture  to  a  tightly  coupled  SOS  architecture,  but  too  often,  issues 
and  problems  were  perceived  as  individual  software  releases  geared  to  stovepipe 
solutions.  Horizontal  integration  was  the  driving  force  behind  PASS;  however,  very 
few  in  the  community,  from  developer  to  tester,  perceived  this  as  a  single  SOS  re¬ 
lease.  Therefore,  the  main  effort  focused  on  horizontal  integration  and  interoperability, 
horizontal  network  interface,  and  identifying  and  working  through  the  bandwidth 
constraints.  Additionally,  the  Training  IPT  was  instrumental  in  addressing  the  lack  of 
collective  ABCS  SOS  training — both  horizontal  and  doctrinal — and  working  with  key 
leaders  in  getting  buy-in  of  the  total  battle  command  capability. 


Not  having  a  well-defined  systems  arthitetture 
and  the  interfate  requirements  upfront 
presented  tremendous  developmental 
and  tethnital  thallenges . 


After  the  Fact-Reverse  System  Engineering.  Not  having  a  well-defined  systems 
architecture  and  the  interface  requirements  upfront  presented  tremendous  develop¬ 
mental  and  technical  challenges.  Without  full  product  output  from  the  systems 
engineering  process,  the  metrics  against  which  the  SOS  will  be  measured  were  not 
well-defined.  Although  each  component  within  the  SOS  design  is  well-documented, 
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the  SOS  architecture  and  technical  design  as  a  whole  is  still  being  fine  tuned,  and 
this  impacts  the  horizontal  integration,  interoperability,  and  resultant  test  cases. 

Aggressive  Schedule.  There  was  a  high  level  of  risk  directly  attributable  to  no 
slack  in  the  good  enough  schedule.  Software  had  to  be  mature  on  entry  to  the  CTSF 
in  April  2004  to  meet  a  targeted  fielding  for  OIF  3.  By  the  time  it  left  the  CTSF  in 
the  summer  of  2004,  it  would  have  left  5  months  to  assess,  train,  and  field  the  battle 
command  and  control  system.  Additionally,  each  system  had  to  have  an  approved 
Materiel  Release  (MR)  prior  to  the  first  unit  rotating  into  country.  Due  to  time  con¬ 
straints,  this  would  have  required  urgent  MRs.  It  became  evident  that  the  EIPT  had 
to  separate  the  fielding  and  development  process.  The  EIPT  was  an  excellent  forum 
to  address  and  focus  developmental  efforts  in  answering  basic  questions  such  as: 

■  What  are  the  operational  capabilities  required  for  the  system  to  reach  good  enough 
criteria? 

■  Of  those  capabilities,  what  can  be  met  today  without  any  additional  software 
upgrades? 

■  Of  the  capabilities  that  cannot  be  met  today,  what  is  the  added  value  of  continuing 
with  development? 

■  What  is  the  timeline  and  investment  strategy  to  reach  MR? 

■  What  are  the  ABCS  and  Joint  dependency  or  interoperability  issues? 


It  is  diffi<ult  to  improve 
what  tannot  be  measured. 


Metrics.  Software  quality,  software  improvement  progress,  organizational  effec¬ 
tiveness,  test  effectiveness,  and  process  improvement  all  have  associated  metrics.  It 
is  difficult  to  improve  what  cannot  be  measured.  Binary  evaluations  of  pass  or  fail 
do  not  facilitate  improvement.  While  certification  is  a  pass/fail  environment,  test-fix- 
test  should  always  be  one  of  measurement  and  improvement.  The  ISO/IEC  15939 
discusses  in  some  detail  the  measurement  process  in  testing,  and  is  a  good  starting 
place  in  understanding  the  needs  for  software,  process,  and  test  improvement. 
Evaluating  and  understanding  common  test  metrics  has  traditionally  been  part  of  the 
commercial  software  industry  in  deciding  when  a  product  is  ready  to  go  to  market, 
finding  process  issues,  finding  systems  design  issues,  and  measuring  test  effectiveness. 

Operational  Threads.  While  the  threads  developed  for  SWB1  were  far  more 
comprehensive  than  previously  available,  their  accuracy,  stability,  and  utility  have  to 
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be  verified  long  before  they  are  used  to  develop  the  technical  solution.  The  process 
for  approval  and  change  is  overly  bureaucratic  and  cumbersome,  and  its  utility  as 
systems  engineering  documentation  of  ABCS  6.4  is  doubtful  if  it  does  not  conform 
to  accepted  commercial  or  government  standards. 

Management  of  Change.  Because  ABCS  6.4  good  enough  was  not  currently  in 
Army  documentation,  it  required  extensive  coordination  across  several  Army 
organizations  to  manage  the  process.  Additionally,  change  of  this  magnitude  is  a  multi¬ 
year  process  that  required  work-arounds  to  mitigate  risk  to  the  overall  program  and 
compressed  schedule.  Most  processes,  such  as  safety  certification,  security  documen¬ 
tation  and  approval,  materiel  releases,  basis  of  issue  plans,  modified  table  of  equipment 
updates,  and  institutional  training  packages,  allow  some  sort  of  interim  solution  but 
require  extensive  coordination  and  open  and  frequent  communications.  On  the  plus 
side,  a  positive  lesson  learned  was  the  importance  of  defining  expectations  through 
a  senior  leader  review,  which  for  this  EIPT  was  weekly  briefs  or  updates  to  the  PEO 
C3T.  The  first  senior  leader  review  became  a  contract  that  all  product  managers 
understood  and  it  contributed  to  all  delivering  on  time. 


On  the  plus  side,  a  positive  lesson  learned  was 
the  important  of  defining  expettations  through 
a  senior  leader  review,  whith  for  this  EIPT  was 
weekly  briefs  or  updates  to  the  PEO  C3T. 


Much  of  the  development  effort  behind  ABCS  6.4  has  been  focused  on  improving 
interoperability  between  the  different  ABCS  systems  and  on  applying  lessons  learned 
about  digital  battle  command  from  operations  in  Iraq.  We  must  look  for  improvement 
in  the  ongoing  cycle  of  developmental  testing  for  ABCS  SOS. 

Below  is  a  short  list  of  actions  to  mitigate  program  risks: 

■  Design  comprehensive  system  engineering  upfront. 

■  Conduct  a  Business  Process  Reengineering  study  and  develop  a  well-coordinated 
implementation  plan. 

■  Conduct  a  well-developed  system  engineering  design  and  review  upfront. 

■  Develop  and  provide  operational  and  technical  architecture  documentation  with  an 
SOS  focus. 

■  Define  roles  and  expectations  of  supporting  agencies  and  required  coordination 
and  support  of  the  other  Services. 
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■  Address  assumptions  and  perceptions  and  identify  dependencies. 

■  Initiate  early  and  frequent  discussions  with  all  involved  in  the  thread  development 
process.  (This  is  an  important  and  critical  step  in  merging  system  and  operational 
views  into  one.) 

■  Initiate  early  discussions  with  Department  of  Operational  Test  and  Evaluation 
(DOT&E)  and  service  test  agency  stakeholders  to  identify  testing  requirements. 

■  Adhere  to  industry  best  practices  and  conformance  with  Army  and  Standards 
Organizations’  guidance. 

■  Create  Risk  Management,  Quality  Management,  and  Communications  Manage¬ 
ment  Plans. 

■  Initiate  early  and  continual  coordination  with  the  test  community  and  service  staff 
to  deconflict  and  solidify  testing,  training,  fielding,  and  unit  schedules. 

■  Notify  the  Army  leadership  on  testing,  operational,  funding,  training,  fielding,  and 
sustainment  issues  on  a  frequent  basis.  (This  was  instrumental  in  getting  DA  level 
guidance  and  issue  resolution  across  agencies.) 

■  Dedicate  use  of  a  separate  Systems  Integration  Lab  (SIL)  for  early  integration, 
testing,  and  validation  of  fixes. 

■  Develop  products  and  documentation  with  configuration  management  under  the 
appropriate  organization  (TRADOC  for  the  operational  views  [OVs]  and  PEO  for 
the  system  views  [SVs]). 

■  Consolidate  and  simplify  the  operational  threads  to  bring  them  more  in  line  with 
operational  utility. 

■  Develop,  publish,  and  institute  a  staff  training  program. 

■  Encourage  participation  by  the  developer,  tester,  trainer,  and  user  in  developing 
TTPs  and  SOPs.  (This  will  assist  users  in  implementing  workarounds.) 

■  Develop  a  process  to  assist  in  getting  it  institutionalized,  funded,  integrated,  and 
supported. 

■  Review  and  closely  coordinate  the  operational  thread  process.  Create  operational 
and  technical  products  that  adhere  to  the  DoD  Architecture  Framework  (DoDAF). 
(With  the  OV  products  prepared  well  in  advance,  they  can  be  traced  back  to  the 
formal  requirements  documents  and  would  more  directly  reflect  the  requirements. 
Likewise  the  SV  and  technical  view  (TV)  products  would  better  reflect  the  technical 
solution  to  the  operational  requirement.) 
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■  Separate  test  executors  from  the  test  planners.  (The  Test  IPT  lead  is  needed  outside 
of  test  community.) 

■  Put  architectural  products,  as  defined  by  the  DoDAF,  under  appropriate  Configu¬ 
ration  Management  (CM).  (As  a  minimum,  the  Combat  Developer  should  develop 
the  required  OV  1,  2,  3,  6c  products  and  the  materiel  developer  the  SV  1,  2,  6  and 
10c  products.  The  SV  products  need  to  be  developed  and  put  under  PEO  CM  and 
OV  products  developed  under  CM  of  TRADOC.) 

■  Develop  a  detailed  Test  Risk  Management  Plan.  (A  detailed  quality  plan  and  metrics 
that  meets  with  current  industry  best  practices  should  be  developed  for  both  test 
and  SOS.) 

■  Conduct  detailed  systems  engineering  that  is  focused  on  the  network-centric 
architecture  for  Net-Centric  Warfare. 

■  Develop  a  reference  implementation  guide  and  repository  containing  a  set  of 
reusable  software  components.  (It  must  describe  how  to  reuse  existing  software 
and  how  to  properly  build  new  software  so  that  integration  is  seamless  and,  to  a 
large  extent,  automated.) 

■  Put  in  place  an  effective  software  infrastructure  for  supporting  mission-area 
applications,  a  set  of  guidelines,  and  standards  and  specifications. 

■  Form  a  separate  focused  IPT  for  training.  (Initially,  it  was  part  of  the  Logistics  IPT 
but  the  volume  of  coordination  with  the  user  community  and  the  development  of 
numerous  training  products  required  the  formation  of  a  focused  IPT  for  training.) 


LEADERSHIP  CHALLENGE 

The  designation  of  an  ABCS  6.4  good  enough  trail  boss  led  directly  to  the  miti¬ 
gation  of  leadership  challenges.  The  effort  required  working  with  a  diverse  set  of 
product  managers  who  are  not  within  the  leadership  chain,  while  at  the  same  time 
supporting  an  Army  at  war.  It  was  a  new  way  of  doing  business.  The  IPT  structure 
that  was  developed  and  implemented  led  to  a  common  focus  on  developing  good 
enough  capabilities  and  fielding  those  capabilities  now. 

In  addition  to  standardizing  and  determining  a  good  enough  Battle  Command 
capability  based  upon  findings  from  Operation  Enduring  Freedom  (OEF)/OIF,  the 
trail  boss,  through  the  EIPT,  facilitated  a  change  from  a  bottom-up  to  a  top-down 
architecture  focusing  on  the  seven  Critical  Commander’s  Needs,  defining  guidance 
on  development  of  the  current  software  and  enhancing  the  operational  and  technical 
architecture,  and  serving  as  a  conduit  for  the  reception  and  dissemination  of  evolving 
and  emerging  Army  direction  for  the  road  ahead. 

The  EIPT  was  a  successful  synchronizing  function.  The  extensive  use  of  the  EIPT 
allowed  for  rapid  identification  of  issues  with  the  appropriate  tasking  for  resolving 
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technical  issues  on  a  very  constrained  timeline.  By  carefully  monitoring  and  manag¬ 
ing  the  system  engineering  process  and  deliveries,  the  program  as  a  whole  was  able 
to  make  significant  progress  that  was  measured  in  weeks  rather  than  months.  The 
trail  boss  concept  worked,  and  it  allowed  a  coordinated  transition  of  focus  over  time. 
The  EIPT’s  major  early  effort  was  technical  development  with  supporting  planning 
efforts  in  logistics,  training,  and  testing.  Over  time,  the  EIPT’s  priority  transitioned 
to  testing,  then  training,  and  now  on  logistics.  A  lesson  learned,  however,  was  that 
while  the  focus  changes  over  time,  all  areas  require  some  level  of  attention  through¬ 
out  the  effort.  During  the  early  good  enough  development,  attention  to  test  planning 
was  inadequate,  leading  to  inefficiencies  when  formal  testing  began. 


CONCLUSION 

An  operational  assessment  of  the  Army’s  Battle  Command  System  was  conducted 
by  several  Army  agencies  in  theater.  As  a  result,  the  Army  requested  that  PEO  C3T 
provide  additional  capabilities  termed  good  enough.  The  PEO  C3T  and  the  ABCS  6.4 
good  enough  EIPT  worked  hard  to  provide  an  architecture  that  is  integrated  across 
all  mission-area  command  and  control  systems.  This  collaborative  work  effort  has 
developed  a  good  enough  solution  called  ABCS  6.4;  and  in  the  spring  of  2005,  the 
ATEC  will  conduct  an  operational  evaluation  of  ABCS  6.4  in  terms  of  its  good  enough 
capabilities  meeting  commander’s  needs. 


With  the  ongoing  effort  and  emphasis  on 
modeling  and  simulation  to  support  SOS 
development,  ABCS  6.4  will  spiral  t ethnology 
in  as  it  betomes  available . 


The  trail  boss  concept  worked  and  the  EIPT  was  a  success  as  a  synchronizing 
function.  In  addition  to  providing  current  capabilities  to  the  force,  the  current  devel¬ 
opmental  efforts  will  further  position  ABCS  6.4  in  supporting  the  Army’s  Objective 
Force.  The  PEO  C3T  is  currently  conducting  an  extensive  review  of  our  basic  system 
engineering  and  integration  processes  that  continues  its  focus  on  the  FCS  SOS.  Because 
information  technology  will  not  sit  still,  good  enough  is  in  fact  not  good  enough.  It 
is  recognized  that  if  the  capability  is  not  provided,  the  warfighter  will  get  it  himself. 
With  the  ongoing  effort  and  emphasis  on  modeling  and  simulation  to  support  SOS 
development,  ABCS  6.4  will  spiral  technology  in  as  it  becomes  available.  Spirals 
down  the  road  in  support  of  the  Joint  Tactical  Common  Operational  Picture  (JCOP) 
Workstation  include  getting  on  a  common  maneuver  baseline  with  the  U.S.  Marine 
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Corps  and  Command  Post  of  the  Future  (CPOF)  to  provide  joint  collaboration.  This 
system  engineering  review  will  examine  how  the  PEO  can  better  support  joint 
interoperability  throughout  the  software  production  lifecycle. 

The  EIPT  is  a  good  tool  for  developing  innovative  approaches  to  build  interoperable 
systems.  The  PEO  C3T  is  better  served  by  using  the  ABCS  6.4  EIPT’s  strong  infra¬ 
structure  to  provide  a  more  dynamic  and  flexible  organization  that  will  work  through 
the  complex  issues  as  it  develops,  tests,  trains,  and  fields  the  Army’s  net-centric 
battlefield  command  and  control  system.  A  brief  description  of  each  battlefield  func¬ 
tional  area  system  is  found  in  the  Appendix. 
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APPENDIX 

ABCS  6.4  NETWORK  BATTLEFIELD 
FUNCTIONAL  AREA  SYSTEMS 


Advanced  Field  Artillery  Tactical  Data  System  (AFATDS)  -  The  AFATDS  pro¬ 
vides  the  multi-Service  (Army  and  U.S.  Marine  Corps)  automated  Fire  Support 
Command  Control,  and  Communications  portion  of  the  Army  Battle  Command 
System  (ABCS).  The  AFATDS  enables  the  maneuver  commander  to  plan  and 
attack  using  the  optimal  weapon-target  pairing  combinations.  AFATDS  provides 
integrated  automated  support  for  planning,  coordinating,  and  controlling  all  fire 
support  assets  (field  artillery,  mortars,  close  air  support,  naval  gunfire,  attack 
helicopter,  and  offensive  electronic  warfare)  and  for  executing  counterfire, 
interdiction,  and  suppression  of  enemy  targets. 

Air  and  Missile  Defense  Planning  and  Control  System  (AMDPCS)  -  The  AMDPCS 
provides  air  defense  planning,  monitoring,  and  air  battle  management  capabili¬ 
ties.  It  integrates  air  defense  (AD)  fire  units,  sensors,  and  C2  centers  into  a  coherent 
system  capable  of  defeating  or  denying  the  aerial  threat. 

AIS/Foundation  Products  -  The  ABCS  Information  Server  (AIS)  acts  as  an  infor¬ 
mation  hub,  providing  critical  data  to  the  Battlefield  Functional  Areas  (BFAs)  to 
include  alerts,  messaging,  communications,  and  address  books. 

All-Source  Analysis  System  (ASAS)  -  The  ASAS  is  the  ABCS  intelligence  fusion 
system  that  provides  a  timely,  accurate,  and  relevant  picture  of  the  enemy  situation 
to  warfighters.  It  provides  combat  leaders  all  source  intelligence  to  support 
visualization  of  the  battlefield  and  so  support  more  effective  conduct  of  the  land 
battle.  The  system  capabilities  allow  the  soldier  to  collaborate  with  other  systems, 
process  and  analyze  all  source  intelligence,  support  non-structured  threat  analysis, 
provide  predictive  analysis,  produce  a  correlated  ground  picture,  disseminate 
intelligence  products,  and  provide  target  nominations.  It  also  supports  manage¬ 
ment  of  intelligence,  surveillance,  reconnaissance  assets,  intelligence  collection, 
provision  of  Combat  Intelligence/Operations  Security  (CI/OPSEC)  mission  sup¬ 
port,  provision  of  electronic  warfare  support,  and  force  protection.  The  ASAS 
interoperates  with  organic  Intelligence  and  Electronic  Warfare  (IEW)  sensors; 
ABCS,  Joint,  Theater,  and  National  sensors  and  preprocessors;  as  well  as  other 
Service  intelligence  processors.  The  ASAS  Light  (ASAS-L)  will  be  the  chief  in¬ 
telligence  fusion  platform  at  corps  and  division  echelons  in  the  ABCS-equipped 
units. 

Battle  Command  Sustainment  Support  System  (BCS3)  -  The  BCS3  is  the  Army’s 
maneuver  sustainment  C2  system  that  provides  a  concise  picture  of  unit  logistical 
requirements  and  support  capabilities.  It  provides  a  running  estimate  of  evolving 
logistics  situations  including  assessments  of  current  and  future  combat  power  that 
is  essential  for  warfighters  to  assess  their  unit’s  capability  to  complete  their  mission. 
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The  BCS3  integrates  the  logistics  common  picture  maintaining  and  generating 
CSS  feeds  to  the  running  estimate  requirement  as  well  as  bringing  in-transit 
visibility  to  the  running  estimate  by  assessing  the  impact  of  “dues  in”  on  the 
current  situation,  enabling  the  warfighter  to  view  material  in  the  logistics  pipe¬ 
line.  This  is  key  to  the  accuracy  of  the  running  estimates  (i.e.,  projecting  changes 
in  asset  status  in  24-,  48-,  and  72-hour  representations). 

Digital  Topographic  Support  System  (DTSS)  -  The  DTSS  provides  automated  sup¬ 
port  for  terrain  mapping  and  analysis  and  creation  of  topographic  products  within 
the  timeframes  required  by  today’s  Army.  It  provides  geospatial  data  generation, 
collection,  and  management;  geospatial  information  processing,  presentation,  and 
analysis;  and  engineer  survey  and  map  reproduction  needs  for  command  and 
control  terrain  visualization. 

Force  XXI  Battle  Command  Brigade-and-Below  (FBCB2)  -  The  FBCB2  supports 
the  control  and  coordination  of  forces  down  to  the  platform  level  (individual  vehicle 
or  aircraft).  It  provides  the  common  picture,  decision  aids,  and  overlay  capabili¬ 
ties  to  support  tactical  commanders  and  staffs,  and  provides  links  from  the  lowest 
echelons  into  the  other  ABCS  systems.  This  information  is  available  in  near-real 
time  and  provides  units  the  capability  to  transmit  key  combat  information  rapidly 
through  formatted  digital  messages. 

Global  Command  and  Control  System — Army  (GCCS-A)  -  The  GCCS-A  is  the 
Army’s  strategic  and  theater  command  and  control  system.  It  provides  readiness, 
planning,  mobilization  and  deployment  capability  information  for  the  strategic 
commanders.  For  theater  commanders,  GCCS-A  provides  Common  Operational 
Picture  (COP)  and  associated  friendly  and  enemy  status  information,  force  em¬ 
ployment  planning  and  execution  tools  (receipt  of  forces,  staging,  intra-theater 
planning,  readiness,  force  tracking,  onward  movement,  and  execution  status),  access 
to  GCCS  applications  for  users  with  the  appropriate  permissions,  and  overall 
interoperability  with  Joint,  Coalition,  and  other  ABCS  Battlefield  Automated 
Systems  (BASs). 

Integrated  Meteorological  and  Environmental  Terrain  System  (IMETS)  -  The 

IMETS  provides  weather  analysis  to  commanders  at  all  echelons  with  an  auto¬ 
mated  tactical  weather  system  that  receives,  processes,  and  disseminates  weather 
observation  forecasts,  battlefield  visualization,  and  weather  effects  decision  aids 
to  all  BASs. 

Integrated  System  Control  (ISYSCON)  Version  (V)4  -  The  ISYSCON  (V)4  provides 
communications  system  network  management,  control,  and  planning.  The 
ISYSCON  (V)4,  also  known  as  the  Tactical  Internet  Management  System  (TIMS), 
provides  network  initialization,  local  area  network  (LAN)  management  services, 
and  an  automated  system  to  support  the  combat  net  radio-based  wide  area  network. 
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Maneuver  Control  System  (MCS)  -  The  MCS  gives  commanders  and  staffs  the 
ability  to  collect,  coordinate,  and  act  on  near-time  battlefield  information  and 
graphically  visualize  the  battlefield.  The  MCS  integrates  information  horizon¬ 
tally  and  vertically  to  provide  the  common  picture  of  friendly  and  enemy  unit 
locations.  As  the  primary  automated  tool  for  commanders  and  staffs  from  corps 
to  battalion  level,  it  is  relied  on  to  provide  the  Common  Operational  Picture, 
decision  aids,  and  facilities  for  development  and  dissemination  of  plans  and  orders. 

Tactical  Airspace  Integration  System  (TAIS)  -  The  TAIS  provides  automated  support 
for  Army  Airspace  Command  and  Control  (A2C2)  and  Air  Traffic  Services  (ATS) 
operations.  The  TAIS  supports  A2C2/ATS  operations  from  Echelons  Above  Corps 
(EAC)  down  to  the  division  level  (and  below  when  task-organized  for  such  roles). 
In  the  A2C2  role,  TAIS  provides  automated  and  digitized  A2C2  planning,  coor¬ 
dination,  and  execution  of  the  third  dimension  of  Army  battlespace.  In  the  ATS 
role,  it  will  support  the  Theater,  Corps,  Divisions,  and  Task  Forces  (as  necessary). 
It  provides  theater  and  intra-  and  inter-Corps/Division  ATS  support  in  war,  and 
provides  a  versatile  airspace  management  system  for  military  operations  other 
than  war  (MOOTW).  The  TAIS  interfaces  with  joint,  combined,  civil,  and  military 
airspace  control  agencies  and  their  airspace  management  systems. 
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